Allow development to accept an age in months relative to origin - #1229
Open
Abhayindia wants to merge 1 commit into
Open
Allow development to accept an age in months relative to origin#1229Abhayindia wants to merge 1 commit into
Abhayindia wants to merge 1 commit into
Conversation
Abhayindia
requested review from
genedan,
henrydingliu,
jbogaardt and
kennethshsu
as code owners
August 26, 2026 23:43
Pyright Type CompletenessView the full Project (full
Other symbols referenced but not exported by
Symbols without documentation:
Patch (exported symbols added or changed by this PR): 100.0% fully typed (3 / 3); 1 no longer exported
Patch symbol details
|
Member
|
just unblocked tests. expecting ruff and codecov fails. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1229 +/- ##
==========================================
- Coverage 91.31% 91.22% -0.09%
==========================================
Files 92 92
Lines 5436 5449 +13
Branches 699 703 +4
==========================================
+ Hits 4964 4971 +7
- Misses 336 340 +4
- Partials 136 138 +2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Abhayindia
force-pushed
the
fix/development-1970-false-positive
branch
from
August 27, 2026 21:54
87a5a8f to
1ac7da2
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #1094 (the enhancement route agreed with @henrydingliu in that thread).
_to_datetimetries%Y%m,%Y,%Y-%m-%dand then falls through to a barepd.to_datetime, which for a numeric column silently reads the values as nanoseconds since epoch. That collapsed age-lag columns like[12, 24, 36]to 1970-01-01, and the old guard just checked whether the result landed in 1970 - so a triangle whose development really is the year 1970 got the same error.This replaces that with a check at the point of parsing: if none of the explicit formats matched and the column is numeric, it's an age in months.
_init_developmentthen resolves each value to the valuation date that many months after the start of that row's origin period. Ages are measured from the origin period start (using the constructor's ownorigin_grain, so mid-period origin dates and fiscal-year anchors line up), not the literal recorded origin date. Bare years still match%Yand are untouched. Non-numeric unparseable input still raises, with the same message as before. Semiannual grains only support the calendar Jan/Jul anchor; a non-calendar one raises a clear error rather than guessing.Verified:
Full suite was 1091 passed / 8 skipped when I posted the branch on the issue.